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[57] ABSTRACT 

A layer two forwarding protocol (L2F) provides virtual 
direct dial-up service into private networks through public 
internet service providers. An authorized remote client 
appears as a direct dial-up client to the home gateway, even 
through the client is accessing the home gateway remotely 
through the ISP. The new forwarding protocol allows the 
remote client to conduct point-to-point link protocols, such 
as point-to-point protocol (PPP) and serial line interface 
protocol (SLIP) directly with the local network home gate- 
way. The network access server changes from a routing 
mode where a communication protocol is conducted with 
the client to a switching mode where the POP simply sends 
data from one port to a tunnel. The tunnel then transmits the 
data to another port, regardless of the header information on 
transmitted data packets. The remote client can then be 
managed through databases controlled by the local network 
and gain access to resources not typically accessible through 
the internet. The layer two forwarding protocol conducts an 
independent authorization session to prevent unauthorized 
access to the private network and provides point-to-point 
protocol transport over the internet independently of internet 
transport protocols, 

31 Claims, 7 Drawing Sheets 
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VIRTUAL DIAL-UP PROTOCOL FOR 
NETWORK COMMUNICATION 

BACKGROUND OF THE INVENTION 

This invention relates generally to network systems and 
more particularly to a virtual dial-up system used for access- 
ing a private local network through an internet access 
service. 

FIG. 1 is a prior art internetwork system 12 which 
includes multiple dial-up network access servers (NAS) 14 
also referred to as points of presence (POPs), The POPs 14 
can be located at different geographical locations around the 
world. An internet service provider (ISP) operates multiple 
POPs 14 through a backbone network 16. The ISP network 
16 is connected to an internet infrastructure, referred to 
generally as internet 18. Different clients 26 dial into a POP 
14 in order to access the internet through the ISP network 16. 

Local Area Networks (LANs) 22 are typically operated by 
private companies and include multiple local clients 26. The 
LAN 22 is connected to internet 18 through a home gateway 
20. The home gateway 20 includes a firewall 28 that 
prevents unauthorized external access into the private net- 
work 22 through internet 18. While some access is possible 
from outside the firewall (e.g., electronic mail), resources 
such as network databases and application programs are 
only accessible by clients located behind the firewall 28. 

An authorized client may need to access files and other 
resources on network 22 from remote locations, such as 
when working at home or while on sales trips. Privately 
operated POPs 24 provide the remote clients with a direct 
dial-up capability to network 22. Since the POP 24 is located 
behind firewall 28, a remote client can dial into POP 24 and 
gain full access to resources on network 22. 

In many instances, it is more cost effective for companies 
to outsource dial-up service to general internet service 
providers, such as ISP 16. However, the firewall 28 in home 
gateway 20 denies access to remote clients that attempt to 
access LAN 22 through a general internet service provider. 

Different network protocols may be used within the 
internet infrastructure and within the private network 22. For 
example, an Internet Protocol (IP) is typically used at the 
network protocol level to send information through the 
internet 18. However, private networks 22 may use any one 
of a variety of network protocols including IP, IPX, 
Appletalk, etc. When a remote client dials into a POP 14, the 
ISP dynamically assigns an IP address to the remote client 
26. Thus, the remote client may be denied access by home 
gateway 20 because the IP address assigned by the ISP 
network 16 is not one of the authorized addresses in the 
LAN 22. The remote client may also be forced by the ISP to 
use an IP protocol incompatible with the local network 22, 
Because the IP protocol and the local LAN protocol are 
incompatible, the remote client is prevented from accessing 
resources on LAN 22. 

Accordingly, a need remains for remote client access to 
private networks through internet service providers while 
maintaining security from unauthorized internet users. 

SUMMARY OF THE INVENTION 

A layer two forwarding protocol (L2F) is integrated with 
existing network protocols to provide a virtual direct dial-up 
service into private networks from internet service provid- 
ers. A remote client accesses an ISP network access server 
(NAS). The NAS determines whether the remote client is 
requesting virtual dial-up service to a local network or 
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standard dial-up service. If virtual dial-up service is 
requested, a tunnel connection is established from the NAS 
to a home gateway for the local network. If the home 
gateway acknowledges the remote client as an authorized 

5 network user, a direct dial-up session is established between 
the NAS and the home gateway. 

The L2F allows the remote client to negotiate with the 
home gateway using a point-to-point link level protocol such 
as point-to-point protocol (PPP). The remote client can then 

3 0 be managed through databases controlled by the local net- 
work and gain access to resources not typically accessible 
through the internet. Thus, the remote client appears as a 
direct dial-up client to the home gateway, even though the 
client is accessing the home gateway remotely through the 

35 ISP. 

A PPP user uses various fink level protocols such as fink 
control protocol (LCP) and network control protocol (NCP) 
to initially negotiate bidirectionally between the remote 
client and the NAS. PPP negotiates physical parameters 

20 between the remote client and the POP. For PPP, an authen- 
tication protocol such as a challenge and authorization 
protocol (CHAP) or a password authentication protocol 
(PAP) is used to verify the remote client identity. During the 
authentication process, the remote client encrypts a random 

25 number based on a remote client password which cannot be 
authenticated by the NAS. Thus, if the remote client dials up 
to the wrong location and the client responds, the dial-up 
server will not receive any password information that can be 
used for unauthorized access to the local network. 

The NAS looks at the remote client name to determine a 
communication destination and requirements for establish- 
ing a tunnel connection with the home gateway. The NAS 
uses L2F to authenticate the remote client with the home 

35 gateway. The home gateway looks through a local database 
for the client name and an associated client password. The 
private system then independently encrypts a random num : 
ber transmitted from the NAS according to the client pass- 
word. If the random number encrypted by the home gateway 

40 matches the random number encrypted by the remote client, 
a tunnel connection is established between the NAS and the 
home gateway. 

If the tunnel connection is established, the NAS is essen- 
tially converted from a PPP endpoint into a switch. In other 

45 words, the NAS changes from a routing mode where a 
communication protocol is conducted with the client to a 
switching mode where the POP simply sends data from one 
port to a tunnel. The tunnel then transmits the data to another 
port, regardless of the header information on transmitted 

50 data packets. 

L2F tunnels at the link level frames (i.e., HDLC and async 
HDLC) of higher level protocols. By using tunnels, it is 
possible to divorce the location of the initial dial-up server 
from the location where the dial-up protocol connection is 

55 terminated and access to the network is provided. The PPP 
session can then be projected from the NAS to the home 
gateway appearing to the home gateway as a direct dial-up 
session. LCP occurs between the client and the NAS for 
establishing subsequent protocols used between the remote 

60 client and the local LAN. For example, an IP control 
protocol (IPCP) can be negotiated to establish communica- 
tion between the internet and an Appletalk protocol (ATPT). 

L2F provides the ability to multiplex multiple clients 
within a tunnel and allows the home gateway to tell different 

65 tunnels apart. From a L2F header, the home gateway deter- 
mines what NAS and client the data is coming from and 
accordingly connects the client to the correct virtual inter- 
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face. The tunneling technique used in conjunction with L2F The virtual dial-up session uses the L2F protocol to 

does not require authentication or address assignment from project a point-to-point link level session (e.g., PPP/SLIP 

the ISP. Thus, termination protocols and updating require- 34) from the NAS 27 to home gateway 20 (e.g., PPP/SLIP) 

ments normally performed by the ISP, and which are incom- 35. Th e PPP/SLIP session 34 is encapsulated in L2F 29 and 

patible with private networks such as IPX and Apple talk, are 5 mc n transmitted from NAS 27, through internet 18, to home 

not necessary. gateway 20. The home gateway uses the L2F protocol 29 to 

TOC7 „ 1+ - , , , • , i to verify that re mote client 32 is an authorized user for LAN 22 

L2F allows multiple protocols and unregistered IP ^ * a 33 NAS %1 ^ ^ 

addresses to be used across existing internet infrasfructure. ga t e way 20. After verification and tunnel establishment, L2F 

Thus, very large investments in access and core infrastruc- 2 9 is used to conduct a direct linklevel session, such as LCP, 

hire can be shared. ™ between remote client 32 and home gateway 20. 

The foregoing and other objects, features and advantages Referring to FIG. 3, the remote client 32 in one 

of the invention will become more readily apparent from the embodiment, comprises a personal computer having a 

following detailed description of a preferred embodiment of processor, memory and a modem. The remote client 32 

the invention which proceeds with reference to the accom- initially dials up a local telephone number for dialing into 

panying drawings. 15 NAS 27. NAS 27 includes a processor, memory and a 

modem for receiving and processing data transmitted from 

BRIEF DESCRIPTION OF THE DRAWINGS the remote client 32. In order to establish communications 

^ . . ,. . over the point-to-point link between remote client 32 and 

FIG. 1 is a pnor art diagram of an internet system. NAS 27, each end of the PPP link must first send LCP 

FIG. 2 is a diagram showing a virtual dial-up session 20 packets to configure and test the data link, 

according to the invention. The NAS 27 uses a modem or a router (not shown) to 

FIG. 3 is a diagram showing different phases of the virtual connect into internet 18. Software in NAS 27 encapsulates 

dial-up session. the PPP session in L2F. Using existing protocols, such as 

FIG. 4 is a step diagram showing steps performed by the Datagram Protocol (UDP) and Internet Protocol (IP), 

network access server when establishing a virtual dial-up 25 NA ? 2 ?„ cr " t " *? * nncl , 33 ^A^l "^"V 18 

& r carries the L2F packet to gateway 20. The home gateway 20 

includes a processor, memory and a modem that connects to 

FIG. 5 is a diagram showing a data structure for a layer internet 18. A two step authentication protocol is then 

two forwarding protocol set-up notification packet. conducted. The NAS 27 and the home gateway 20 first 

FIG. 6 is a step diagram showing steps performed by a 30 perform a bidirectional authentication and then the remote 

home gateway when establishing the virtual dial-up session. client 32 authenticates. If the remote client 32 is authenti- 

HG. 7 is a step diagram showing operation of the network cated as an authorized client for LAN 22, a tunnel connec- 

access server during the virtual dial-up session. tion is made between NAS 27 and home gateway 20 and the 

FIG. 8 is a diagram showing the authentication protocol virtual session & established. The L2F encapsulated 

conducted during a forwarding protocol session. ^ £J P P acket 15 mnneled from NAS 27 t0 nome S atewa y 

FIG. 9 is a diagram of the data structure for the layer two " - * 

forwarding protocol. Remote client 32 and home gateway 20 are then free to 

negotiate NCPs for each protocol. After the PPP session 

DETAILED DESCRIPTION between remote client 32 and home gateway 20 is estab- 

40 lished via tunnel 33, remote client 32 is free to access 

Referring to FIG. 2, remote client 26 is coupled to an res0 urces in LAN 22 without restrictions from the firewall 

Internet Service Provider (ISP) network access server (NAS) 28 in home gateway 20 (FIG. 2) or from incompatible 

27 that accesses the internet infrastructure 18 via a Public network protocols 

Switched Telephone Network (PSTN) 30 (i.e., async PPP via Remote Qienl/NAS Point-to-Point Protocol Session 

modems). Remote client 32 is coupled to a NAS 27 through 45 FIG. 4 is a step diagram describing the initial dial-up 

a port and accesses the internet 18 via an Integrated Services session ^twai remote client 32 ^ NAS 27 The remole 

Digital Network (ISDN) 36 (i.e., synchronous PPP access). clicQt 32 mitiatcs a PPP connection 34 (FIG. 2) to NAS 27 

A private Local Area Network (LAN) 22 includes local m step 40 ^ NAS 27 accepts me coition and the PPP 

clients 23 and is connected to internet 18 through a home Unk ^ csta blished. LCP is negotiated in step 41. 

gateway 20 which includes a firewall 28. NAS 27 is alter- 50 NAS 27 authenticates the client 32 using an authen- 

natively defined as an ISP Point of Presence (POP). tication protocol such „ CHAp ^ step 42 ^ NAS 27 

The hardware and software required to generally operate pursues authentication to the extent required to discover the 

NAS 27, PSTN 30, ISDN 36, internet infrastructure 18, remote client's apparent identity, and by implication, the 

home gateway 20, firewall 28 and local clients 26 and desired home gateway 20. Point-to-point protocols such as 

remote clients 26 and 32 are all well known to those skilled 55 PPP/SLIP and authentication protocols, such as CHAP, are 

in the art and are, therefore, not described in detail. well-known to those skilled in the art and are, therefore, not 

Remote client 32 accesses LAN 22 through a virtual explained in detail, 

dial-up session according to the invention. During the virtual A username field is interpreted by NAS 27 in step 44 to 

dial-up session, the remote client 32 appears as a direct determine whether virtual dial-up service is required. The 

dial-up client to home gateway 20. Thus, remote client 32 60 username is either structured (e.g., bill@localnet.com) or the 

can access any of the resources, such as local clients 23, on NAS 27 maintains a database mapping users to services. In 

LAN 22 through the internet service provider NAS 27. Since the case of virtual dial-up, the mapping will name a specific 

the remote client 32 can access resources from NAS 27, the endpoint, the home gateway 20. If a virtual dial-up service 

company operating LAN 22 is not required to purchase and is not required, standard access to the internet 18 is provided 

maintain private POPs 24 (FIG. 1). Because remote client 32 65 in step 48. 

can utilize a local NAS, long distance calls do not have to When step 46 determines a virtual dial-up is requested 

be made to a dial-up server located at LAN 22. (i.e., the apparent remote client identity is determined), step 
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50 initiates a tunnel connection to the home gateway 20 
using the authentication information gathered by the NAS 
27 in step 42. If a tunnel 33 is already initiated between the 
NAS 27 and home gateway 20, a slot in the tunnel 33 is 
allocated for the remote client 32, Tunneling is provided by 
an existing protocol such as (UDP), Frame Relay permanent 
virtual connections (PVCs), or X.0.25 virtual connections 
described in detail in the following request for comments 
(RFCs) UDP-RFC 768, IP-RFC 791, Frame Relay-RFC 
1490. 

Once the tunnel 33 exists, an unused multiplex ID (MID) 
is allocated, in step 52 and a set-up notification packet (see 
FIG. 5) is sent to notify the home gateway 20 of the new 
dial-up session. The NAS 27 waits for the home gateway 20 
either to accept or reject the set-up notification in step 56. 
Rejection can include a reason indication, which is dis- 
played to the remote client 32. After the rejection is 
displayed, the call from NAS 27 to home gateway 20 is 
disconnected in step 58. If the set-up notification is accepted, 
step 60 connects the call and step 61 establishes the virtual 
dial-up session in step 61. Link level frames are then 
received and transmitted between the two endpoints in step 
63. 

Referring to FIG. 5, a set-up notification packet 62 
includes a L2F header 64, authentication data 65 and LCP 
data 66. The packet 62 is used by the home gateway 20 to 
authenticate the remote client and to decide whether to 
accept or decline the tunnel connection. In the case of 
CHAP, the set-up notification packet authentication data 
includes a random number challenge, username and pass- 
word. For PAP or text dialog (i.e., for SLIP users), the 
authentication information 65 includes username and clear 
text password. The home gateway 20 can use this informa- 
tion to complete remote client authentication, avoiding an 
additional cycle of authentication. 

To initiate a PPP session between the remote client 32 and 
the home gateway 20, the set-up notification packet 62 
includes a copy of LCP parameters 66 for the completed 
LCP negotiation between remote client 32 and NAS 27 
(FIG. 3). The home gateway 20 may use this information to 
initialize its own PPP state avoiding additional LCP nego- 
tiation. The home gateway 20 may alternatively choose to 
initiate a new LCP exchange with remote client 32. 

Referring to FIG. 6, the home gateway 20 receives the 
set-up notification packet 62 sent from the NAS 27 in step 
72. The home gateway 20 conducts remote client authori- 
zation in decision step 74. If the client is not in the home 
gateway 20 local database (FIG. 3), the tunnel slot between 
NAS 27 and home gateway 20 is disconnected in step 76. If 
the remote client is validated as an authorized user, home 
gateway 20 accepts the tunnel connection in step 78. A 
"virtual interface" is established for SLIP or PPP in step 80. 
The virtual interface is established in a manner analogous to 
a direct-dialed connection. With the "virtual interface" in 
place, link level frames are passed over the tunnel in both 
directions in step 82. 

Referring to FIG. 7, after the virtual dial-up session is 
established, frames are received at the NAS 27 in step 83. If 
NAS 27 receives information from remote client 32, the 
frames are stripped of any link framing or transparency bits 
or bytes (physical media encoding) in step 86, encapsulated 
in L2F in step 88, and forwarded over the appropriate tunnel 
slot to home gateway 20 in step 90. The home gateway 20 
accepts these frames, strips L2F, and processes them as 
normal incoming frames for the appropriate interface and 
protocol. 

The home gateway 20 encapsulates packets sent to NAS 
27 in L2F. In step 82, the NAS 27 determines the data is 
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coming from the tunnel slot connected to the home gateway 
20. The frame is stripped of L2F in step 92 and transmitted 
out its physical interface (e.g., modem) to the remote client . 
32 in step 94. 

s The connectivity between remote client 32 and home 
gateway 20 is a point-to-point PPP or SLIP connection 
whose endpoints are the remote client's networking appli- 
cation on one end and the termination of this connectivity 
into the home gateway's SLIP or PPP virtual interface on the 

10 other end. Because the remote client becomes a direct 
dial-up client of the home gateway access server, client 
connectivity can now be managed by the home gateway 20 
with respect to further authorization, protocol access, and 
filtering. Accounting can be performed at both the NAS 27 

55 as well as the home gateway 20. 

Because the L2F set-up notification packet 62 for PPP 
remote clients contain sufficient information for the home 
gateway 20 to authenticate and initialize an LCP state 
machine 23, it is not required that the remote client 32 be 

20 queried a second time for CHAP authentication, nor that the 
client undergo multiple rounds of LCP negotiation and 
convergence. Thus, connection set-up between the remote 
client 32 and home gateway 20 is optimized and transparent. 
Addressing 

25 There are several significant differences be tween standard 
internet access service and the virtual dial-up service with 
respect to authentication, address allocation, authorization 
and accounting. The mechanisms used for virtual dial-up 
service coexist with the internet protocol's traditional 

30 mechanisms and allow the NAS 27 to simultaneously ser- 
vice standard ISP clients as well as virtual dial-up clients. 

For an internet service, an IP address may be allocated to 
the remote client dynamically from a pool of service pro- 
vider addresses. Thus, the remote user has little or no access 

35 to their home network's resources, due to firewalls and other 
security policies applied by the home network to accesses 
from external IP addresses. 

For L2F virtual dial-up, the home gateway 20 exists 
behind the home firewall and allocates addresses which are 

40 internal to the home LAN 22, such as non-IP addresses. 
Because L2F is tunneled exclusively at the frame level, the 
policies of such address management protocols are irrel- 
evant for correct virtual dial-up service; for all purposes of 
PPP or SLIP protocol handling, the dial-up user appears to 

45 have connected at the home gateway 20. 
Remote Client Authentication 

The authentication of the remote client occurs in three 
phases; the first authentication phase occurs at the ISP, and 
the second and optional third authentication phase occurs at 

50 the home gateway 20, 

The ISP uses the username to determine that a virtual 
dial-up service is required and initiates the tunnel connection 
to the appropriate home gateway 20. Once a tunnel is 
established, a new multiplex ID is allocated and a session 

55 initiated by forwarding the gathered authentication informa- 
tion. 

The home gateway 20 undertakes the second phase by 
deciding whether or not to accept the connection. The 
connection indication may include CHAP, PAP, or textual 

60 authentication information. Based on this information, the 
home gateway 20 may accept the connection, or may reject 
it (for instance, it was a PAP request and the username/ 
password are found to be incorrect). Once the connection is 
accepted, the home gateway 20 is free to pursue a third phase 

65 of authentication at the PPP or SLIP level such as proprietary 
PPP extensions, or textual challenges carried via a TCP/IP 
telnet session. 
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FIG. 8 is a diagram showing the authorization steps 
conducted while establishing a virtual dial-up session. In 
step 1, various link level protocols such as LCP are used to 
initially negotiate bidirectionally between the remote client 
32 and the NAS 27. In step 2, a challenge such as CHAP is 
transmitted from NAS 27 to the remote client 32. During the 
challenge, the NAS 27 sends a random number (R) to remote 
client 32. 

In step 3, the remote client encrypts the random number 
R based on a remote client password (pwd). The password 
is a shared secret between remote client 32 and home 
gateway 20. The encrypted password cannot be authenti- 
cated by the NAS 27. Thus, if the remote client 32 dials up 
to the wrong location and responds, the dial-up server will 
not receive any password information that can be used for 
unauthorized access to the local network. The encryption of 
R according to the password (C(R)pwd) is conducted using 
an existing encryption algorithm such as CHAP which is 
known to those skilled in the art. The remote client name, 
and the encrypted random number are transmitted back to 
NAS 27. 

In step 4, based on the remote client name, the NAS 32 
establishes a tunnel to home gateway 20, The NAS 32 
transmits the remote client name, the random number, the 
encrypted random number C(R)pwd and the LCP session 
through the tunnel to the home gateway 20. The home 
gateway 20 then independently encrypts the random number 
R according to the client password which is prestored in the 
home gateway database. If the random number encrypted by 
the home gateway 20 matches the random number encrypted 
by the remote client 32, a virtual interface is established 
between the NAS 27 and the home gateway 20. An optional 
authorization step 5 can be conducted in a PPP session 
between remote client 32 and home gateway 20. 
Accounting 

The home gateway 20 can decline a connection based on 
the authentication information collected by the NAS 27. 
Accounting can easily draw a distinction between a series of 
failed connection attempts and a series of brief successful 
connections. Because authentication is conducted before 
allowing the tunnel connection, spurious connection costs 
will be prevented by remote clients failing the authentication 
session. 

Since virtual dial-up is an access service, accounting of 
connection attempts (in particular, failed connection 
attempts) is important. The home gateway 20 can accept 
new connections based on the authentication information 
gathered by the NAS 27 with corresponding logging. For 
cases where the home gateway 20 accepts the connection 
and then continues with further authentication, the home 
gateway 20 might subsequently disconnect the client. For 
such scenarios, the disconnection indication back to the 
NAS 27 may also include a reason. 
L2F Protocol Definition 

The layer two forwarding protocol (L2F) used during a 
virtual dial-up session operates as follows. 

The NAS 27 and the home gateway 20 each have software 
that provide a common understanding of the L2F encapsu- 
lation protocol so that SLIP/PPP packets can be successfully 
transmitted and received across the internet 18. The PPP/ 
SLIP packets are encapsulated within L2F. The encapsulated 
packet is the same packet as it would be transmitted over a 
physical link. The entire encapsulated packet includes a L2F 
header, payload packet for SLIP or PPP and an optional 
Checksum. 

FIG. 9 is a detailed diagram showing the data structure of 
the L2F packet. 
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Version Field 

The Ver ("Version"') field represents the major version of 
the L2F software creating the L2F packet. 

If any bits are non-zero after bit S, but before bit C, an 
5 implementation must discard the packet and initiate discon- 
nect of the entire tunnel. This would correspond to a packet 
containing extensions not understood by the receiving end. 
Handling of the "Key" field must be taken in preference to 
this processing, to avoid denial-of-service attacks. Bit P is 
10 used for priority status and bit S is used for sequence 
numbering. 
Protocol Field 

The protocol field ("PROTOCOL") specifies the protocol 
carried within the L2F packet. Legal values (represented 
15 here in hexadecimal) are: 



Value 


Type 


Description 


0x00 


L2F_ILLEGAL 


Illegal 


0x01 


L2F__PROTO 


L2F management packets 


0x02 


L2F_PPP 


PPP tunneled inside L2F 


0x03 


L2F_SLIP 


SLIP tunneled inside L2F 



Sequence Number 

25 The Sequence number starts at 0 for the first L2F packet 
under a tunnel. Each subsequent packet is sent with the next 
increment of the sequence number. The sequence number is, 
thus, a free-running counter represented by modulo 256. For 
non-L2F management packets, the sequence number is 

30 transmitted as 0 and does not increment the local sequence 
counter, and does not affect the processing of received 
traffic. For L2F management packets, the sequence number 
is used to protect against duplication of packets, as follows: 
The receiving side of the tunnel records the sequence 

35 number of each valid L2F packet it receives. If a received 
packet appears to have a value less than or equal to the 
last-received value, the packet must be silently discarded. 
Otherwise, the packet is accepted and the sequence number 
in the packet is recorded as the latest value last received. 

40 For purposes of detecting duplication, a received 
sequence value is considered less than or equal to the 
last-received value if its value lies in the range of the last 
value and its 127 successor values. For example, if the 
last-received sequence number is 15, packets with sequence 

45 numbers 0 through 15, as well as 144 through 255, would be 
considered less than or equal to, and would be silently 
discarded. Otherwise it would be accepted. 
Multiplex ID 

The Multiplex ID ("MID") identifies a particular connec- 

50 tion within the tunnel. Each new connection is assigned a 
MID currently unused within the tunnel. The MID cycles 
through the entire 32-bit namespace, to reduce aliasing 
between previous and current sessions. The MID with value 
0 is special; it is used to communicate the state of the tunnel 

55 itself, as distinct from any connection within the tunnel. 
Client ID (CLID) 

The Client ID is used to assist endpoints in demultiplex- 
ing tunnels when the underlying point-to point substrate 
lacks an efficient or dependable technique for doing so 

60 . direcdy, Using CLID, it is possible to demultiplex multiple 
tunnels whose packets arrive over the point-to-point media 
interleaved, without requiring media-specific semantics. 

When transmitting a L2F__CONF message (described 
below), a peer's CUD must be communicated via an 

65 assigned_CLID field. This must be a unique non-zero value 
on the sender's side, which is to be expected in all future 
non-L2F_CONF packets received. The CUD value from 
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the last valid L2F_CONF message received should be 
recorded and used as the CLID field value for all subsequent 
packets sent to the peer. Packets with an unknown CUD are 
silently discarded. 

For the initial packet sent during tunnel establishment, 
where no L2F__CONF has yet been received, the CLID field 
is 0. Thus, during L2F_CONF, each side is told its CUD 
value. All later packets sent and tagged with this CUD 
value, serve as a tag which uniquely identifies this peer. 
Length 

Length is the size in octets of the entire L2F packet, 
including header, all fields present, and payload. Length 
does not reflect the addition of the Checksum, if one is 
present. The L2F packet is silently discarded if the received 
packet is shorter than the indicated length. Additional bytes 
presented in the packet beyond the indicated length are 
ignored. 

Packet Checksum 

The Checksum is present if the C bit is present in the 
header flags. It is a 16-bit CRC as used by PPP/HDLC. It is 
applied over the entire packet starting with the first byte of 
the L2F flags, through the last byte of the payload data. 
Payload Offset 

The Offset is present if the F bit is set in the header flags. 
This field specifies the number of bytes past the header at 
which the payload data is expected to start. If it is 0 or if the 
F bit is not set, the first byte following the last byte of the 
L2F header is the first byte of payload data. 
Packet Key 

The Packet Key is the authentication response last given 
to the peer during tunnel creation. It serves as a key during 
the life of a session to resist attacks based on spoofing. If a 
packet is received in which the Key does not match the 
expected value, the packet is silently discarded. 
L2F Tunnel Establishment 

When the point-to-point link is first initiated between the 
NAS 27 and the home gateway 20, the endpoints commu- 
nicate on MID 0 prior to providing general L2F services to 
clients. This communication is used to verify the presence of 
L2F on the remote end, and to permit any needed authen- 
tication. 

The protocol for such negotiation is always 1, indicating 
L2F management. The message itself is structured as a 
sequence of single octets indicating an option, followed by 
zero or more further octets formatted as needed for the 
option. 

Normal Tunnel Negotiation Sequence 

The establishment sequence is illustrated by a "typical" 
connection sequence. Detailed description of each function 
follows, along with descriptions of the handling of excep- 
tional conditions. 

Each L2F packet is described as a source— ^destination on 
one line, a description of the L2F packet field contents on the 
next, and the contents of the packet's body on following 
lines. The exact encoding of octets will be described later. 

Note that this example uses the Key option, but does not 
use the Offset and Checksum options. The Length field 
would be present, reflecting the actual length of the packets 
as encoded as an octet stream. 



1. NAS->GW; 

Proto-l^R, Seq-0, MID-0, CUIX), Key«0 
L2F_CONF 

Name: NAS_namc 

Challenge: RND 
Assigaed_CIID: 22 



The NAS 27 decides that a tunnel must be initiated from 
the NAS 27 to the home gateway 20 (GW). An L2F packet 
is sent with the Protocol field indicating that an L2F man- 
agement message is contained. 



Because the tunnel is being initiated, Key is set to 0. The 
sequence number starts at 0; the MID is 0 to reflect the 
establishment of the tunnel itself. Since the NAS 27 has not 
yet received an L2F„CONF, the CLID is set to 0. 
S The body of the packet specifies the claimed name of the 
NAS 27, and a challenge random number (RND) which GW 
20 will use in authenticating itself as a valid tunnel endpoint. 
Assigned__CLID is generated to be a value not currendy 
assigned out to any other tunnel to any other home gateway. 

10 

2. GW->NAS: 

Proto-L2F, Seq=0, MtD-0, CUD-22, Key-C(Rnd) 
L2F_CONF 

Name: GW_namc 
Challenge: Rnd2 
15 Afisigned_CLID: 73 



The home gateway 20 has processed the previous packet 
and sends a response. The protocol continues to be L2F, with 

^ a sequence number 0 (each side maintains its own sequence 
number for transmissions). MID continues to be 0 to reflect 
tunnel establishment. CLID reflects the Assigned_CUD 
field of the L2F_CONF received. The Key is a CHAP-style 
. hash of the random number received; each packet hereafter 
will reflect this calculated value, which serves as a key for 

25 the life of the tunnel. 

The body contains the name of home gateway 20 and its 
own random number challenge and its own Assigned_CLID 
for the NAS 27 to place in the CLID field of future packets. 
The CLID is generated in an analogous manner to that of the 

30 NAS 27. After this, all packets received by GW 20 must be 
tagged with a CUD field containing 73, and all packets sent 
to the NAS 27 must be tagged with a CLID field containing 
22. 



3. NAS->GW 

Proto=L2F, Seqol, M[D=0, CLID-73, Key=C(Rnd2) 
L2F_OPEN 



The NAS 27 responds with its Key now set to reflect the 
shared secret. Like the home gateway 20, the NAS 27 will 
use this Key for the life of the tunael. 



4. GW->NAS 

45 Proto-L2F, Seq-1, MtD-0, CUD-22, Key-C(Rnd) 
L2F_OPEN 



The home gateway 20 provides closure of the key from 
the NAS 27. The tunnel is now available for clients to be 
50 established. 

Normal Client Negotiation Sequence 

This section describes the establishment of a virtual 
dial-up client on a NAS 27 into a home gateway 20. It . 
assumes a tunnel has been created in the way described 
55 above. The client for this example is a PPP client configured 
for 



65 Response: <Value received, presumably C(Rnd3)> 

The NAS 27 has received a call, tried CHAP with a 
challenge value of Rnd3, and found that' the client 



1. NAS->GW 

Proto»L2F, Seq-2, MID-1, CUD-73, Key-C(Rnd2) 
«0 L2F_OPEN 

Authen: CHAP 
Client: CHAP-name 
Challenge: Rnd3 
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responded. The claimed name leads the NAS 27 to believe 
it was a virtual dial-up client hosted by the home gateway 
20. The next free MID is allocated, and the information 
associated with the CHAP challenge/response is included in 
the connect notification. 



2. GW->NAS 

Proto-L2F, Scq-2, MID-1, CLID-22, Key-C(Rnd) 
L2F_OPEN 



The home gateway 20, by sending back the L2F_OPEN, 
accepts the client. 



3. NAS->GW 

Proto-PPP, Seq=0, MID-1, CLID=73, Key=C(Rnd2) 
<Framc follows> 

4. GW->NAS 

Proto-PPP, Seq=0, MID-1, CL1D-22, Kcy-C(Rnd) 
<Framc follows> 



Traffic is now free to flow in either direction as sent by the 
remote client 27 or any home site on LAN 22 (FIG. 2). The 
contents of the L2F frames is uninterpreted data such as 
High Level Data Link Control (HDLC). Data traffic, since it 
is. not the L2F protocol, does not use the Seq field, which is 
set to 0 in non-L2F messages. 
L2F Management Message Types 

When a L2F packet's Proto field specifies L2F 
management, the body of the packet is encoded as zero or 
more options. An option is a single octet "message type", 
followed by zero or more sub-options. 

Each sub -option is a single byte sub-option value, and 
further bytes as appropriate for the sub-option. 

Options in L2F are: 



Hex Abbreviation Description 



0x00 


Invalid 


Invalid message 


0x01 


L2F_CONF 


Request configuration 


0x01 


L2F_CONF_TYPE 


Type of authentication used 


0x02 


L2F_CONF NAME 


Name of peer sending L2F_CONF 


0x03 


L2F_CONF_CHAL 


Random # peer challenges with 


0x04 


L2F_CONF_CLTO 


Assigned_CLID for peer to use 


0x02 


U2F_OPEN 


Accept configuration 


0x01 


L2F_OPEN_CHAP 


CHAP name received from client 


0x02 


L2F_OPEN_CHAL 


Challenge CHAP client received 


0x03 


L2F_OPEN_RESP 


CHAP challenge response from client 


0x04 


L2F _ACK_LCP1 


LCP CONFACK accepted from client 


0x05 


L2F _ACK_LCP2 


LCP CONFACK sent to client 


0x03 


L2F_CLOSE 


Request disconnect 


0x01 


L2F_CLOSE_WHY 


Reason code for close 


0x02 


L2F_CLOSE_STR 


ASCII string description 


0x04 


L2F_ECHO 


Vferify presence of peer 


0x05 


L2F_ECH0_RESP 


Respond to L2F_ECHO 



L2F Message Type: Invalid 

If a message is received with this value, or any value 
higher than the last recognized option value, the packet is 
considered invalid. The packet is discarded, and a L2F_ 
CLOSE of the entire tunnel is requested. Upon receipt of a 
L2F_CLOSE, the tunnel itself may be closed. All other 
received messages are discarded. An implementation may 
also close the tunnel after an interval of time appropriate to 
the characteristics of the runnel. Invalid sub-option values, 
even if present under a valid option, are treated as if the 
entire message type was invalid. 
L2F_CONF 

The L2F message type is used to establish the tunnel 
between the NAS 27 and the home gateway 20. MID is 
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always set to 0. The body of such a message starts with the 
octet 0x01 (L2F_CONF), followed by one or more sub- 
options. 

The L2F_CONF_TYPE sub-option must be present. It is 
5 encoded as the octet 0x01, followed by a single byte 
describing the type of authentication the NAS 27 exchanged 
with the remote client 32 in detecting the client's claimed 
identification. The authentication types are: 
0x01 Textual username/password exchange 
10 0x02 PPP CHAP 
0x03 PPP PAP 

The L2F_CONF_J^AME sub-option must be present. It 
is encoded as the octet value 0x02, followed by an octet 
specifying a non-zero length, followed by the indicated 
15 number of bytes, which are interpreted as the sender's ASCII 
name. 

The L2F_CONF__CHAL sub-option must be present. It 
is encoded as the octet value 0x03, followed by four bytes 
of challenge value. The challenge value is generated using a 
random number generator. 

20 The L2F_CONF_CLID sub-option must be present. It is 
encoded as the octet 0x04, followed by four bytes of 
Assigned„CLID value. The Assigned_CLID value is gen- 
erated as a non-zero value unique across all runnels which 
exist on the sending system. 

25 The CLID field is sent as 0 when a L2F 13 CONF packet 
is received from the peer. After this, the Assigned_CUD 
value of the last L2F_CONF packet received must be 
placed in the CLID of all packets being sent When sent from 
a NAS to a home gateway, the L2F_CONF is the initial 

30 packet in the conversation. Key is set to 0, since no chal- 
lenge has been received yet. 

When sent from the home gateway 20 to the NAS 27, a 
L2F_CONF indicates the home gateways recognition of the 
tunnel creation request. The home gateway 20 must provide 

35 its name and its own challenge in the message body. Key 
must be set to the CHAP-style hash of the received challenge 
bytes. 

L2F__OPEN 

The L2F_OPEN message is used to establish a client 

40 connection within a tunnel previously established by L2F_ 
CONF messages. When sent from the NAS 27 to the home 
gateway 20, it is used to indicate the presence of a new 
dial-up client. When sent back from the home gateway 20 to 
the NAS 27, it indicates acceptance of the client. This 

45 message starts with the octet 0x02. When sent from the NAS 
27, it may contain further sub-options. When sent from the 
home gateway 20, it may not contain any options. 

The L2F_OPEN_CHAP sub-option is encoded as the 
octet 0x01, followed by an octet specifying the length of the 

50 CHAP name received, followed by the indicated number of 
bytes of CHAP name. 

The L2F_OPEN_CHAL sub-option is encoded as the 
octet 0x02, followed by an octet specifying the length of the 
CHAP challenge sent, followed by the CHAP challenge 

55 itself. 

The L2F_OPEN_RESP sub-option is encoded as the 
octet 0x03, followed by an octet specifying the length of the 
CHAP response sent, followed by the client's response to the 
CHAP challenge. This message must be treated as invalid if 

60 L2F__OPEN_CHAP, L2F_OPEN_CHAL, and L2F_ 
OPEN_RESP do not all appear within the same message. 

The L2F_^CieXCPl and L2F_ACK_LCP2 sub- 
options are encoded as the octets 0x04 and 0x05 
respectively, followed in either case by two octets in net- 

65 work byte order specifying the length of the LCP CON- 
FACK last received from or sent to the client. Following 
these octets is an exact copy of the CONFACK packet. 
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The home gateway 20 may choose to ignore any sub- Sequenced Delivery 

option of the L2F_OPEN and accept the connection any- ah L 2F control messages (i.e., those L2F packets with a 

way. The home gateway 20 would then have to undertake its pro tocol type of 0x01) are transmitted with a sequence 

own LCP negotiations and authentication. L2F_CLOSE number ^ seque[lce number fa a pe^p tunne i free . 

Tta message is encoded as the byte 0x03. An L2F_ s coualer which ^ (modulo 2 56) after 

CLOSE may be ^nt by either side of the tunnel at any tome. cach kct ^ traflsmiUed> It is used to it thc rcceivi 

When sent with MID ofO, it indicates the desire to terminate j * j * * j v * j . c j 1 * j * 

4 i j ti i* * *i_ * i TTTi. A end to detect duplicated or out-of-order packets, and to 

the entire tunnel and all clients within the tunnel. When sent ^ r 

from the home gateway 20 in response to an L2F_OPEN, dJscaKl suco packets. 

it indicates that the home gateway 20 has declined the 10 Because L2F in operation carries uninterpreted frames, it 
connection. When sent with a non-zero MID, it indicates the permits operation of features without explicit knowledge of 
termination of that client within the tunnel. these features. For instance, if a PPP session is carried, L2F 
The L2F_CLOSE__WHY sub-option is encoded as the is simply transporting HDLC frames. The two PPP end- 
byte 0x01 followed by four bytes in network byte order points can negotiate higher-level features, such as reliable 
specifying a bit mask of reasons for the disconnection. The 15 link, compression, multi-link, or encryption, 
bits are encoded as: fcaturcs mcn operate between the two PPP end- 
0x00000001 Authentication failed po [ nis ( me dial-up client on one end, and the home gateway 
0x00000002 Out of resources 20 on the other), with L2F continuing to simply ship HDLC 
0x00000004 Administrative intervention frames back and forth. For similar reasons, PPP echo 
0x00000008 User quota exceeded 20 requests, NCP configuration negotiation, and even termina- 
0x00000010 Protocol error tion requests* are all simply tunneled HDLC frames. 
0x00000020 Unknown user Termination 

0x00000040 Incorrect password As L2F simply tunnels link-level frames, it does not 

0x00000080 PPP configuration incompatible is detectframeslikePPPTERMREQ.L2Fterminationinthese 

Bits in the mark OxFFOOOOOO are reserved for per-vendor scenarios is driven from a protocol endpoint; for instance, if 

interpretation. a home gateway 20 receives a TERMREQ, its action will be 

An implementation can choose to not provide status bits to "hang up" the PPP session. The L2F implementation at 

even if it detects a condition described by one of these bits. the home gateway 20 converts a "hang up" into a L2F_ 

For instance, an implementation may choose to not use 30 CLOSE action, which will shut down the client's session in 

0x00000020 due to security considerations, as it can be used the tunnel cleanly. L2F_CLOSE_WHY and L2F_ 

to prove user name space. CLOSE„STR may be included to describe the reason for 

The L2F_CLOSE_STR sub-option is encoded as the the shut-down, 

byte 0x02, followed by a two-byte length in network byte Extended Authentication 

order, followed by the indicated number of bytes, which are 35 j s compatible with both PAP and CHAP protocols, 

interpreted as descriptive ASCII text associated with the slip does not provide authentication within the protocol 

disconnection. This string may be ignored, but could be itself, and thus requires an ASCII exchange of username and 

recorded in a log to provide detailed or auxiliary information password before SLIP is started. L2F is compatible with this 

associated with the L2F_CLOSE. mo de of operation as well. 

L2F_ECHO . * 40 To the extent the NAS 27 can capture and forward the 
Transmission of L2F_ECH0 messages are optional. If an one . time pasaworf L2F operation is compatible with pass- 
implementation transmits L2F ECHO messages, it must WQrd cards For ^ most j an ^ 
not transmit more than one such request each second. Hie rcquest / rcS ponse exchange is supported. In a L2F 
payload s^e must be 64 bytes or less in length. environment, the protocol is structured so that the NAS 27 
The L2F_ECHO message is encoded as the single byte 45 caQ dctcct [hc { ideQtit of ^ user and cstablish a 
0x04 It can be sent by either side once the tunnel is ^ connection to the home gateway 20, where the 
established. MID must be 0. An L2F JCHOJESP must arbi cxch can 0CCUf 

be sent back in response. _ , „ rt , . . , „ 

L2F ECHO RESP home gateway 20 requires authentication before 

AH implementations respond to L2F_ECHO, using 50 acce P lm S a connection from NAS 14. Thus, there will not be 

L2F_JCHO_RESP. The received packet is sent back a spunous run-up of lme toll charges smce me remote chent 

verbatim, except that the CUD, sequence number, and does not first to P nvate s y stem , and the °P/™ de 

Checksum (if any) must be updated, and the L2F_ECHO m appropriate PPP authentication protocol (e.g., CHAP), 

message type changed to an L2F„ECHO_RESP. Payload It should also be apparent that many of the L2F operations 

data following the 0x04 octet, if any, must be preserved in 55 conducted by NAS 27 could be alternative performed in the 

the response. remote client 32. For example, the random number 

When an L2F_ECHO_J*ESP is received, the payload generation, encryption and transmission could be conducted 

data may be used to associate this response with a previously solelv bv the remote client without interaction by the NAS 

sent L2F_ECHO, or the packet may be silently discarded. 27. Also tunneling negotiations and L2F encapsulation could 

L2F Message Delivery 60 similarly be conducted in the remote client instead of the 

L2F is designed to operate over point-to-point unreliable NAS 27. 

links. It is not designed to provide flow control of the data Having described and illustrated the principles of the 

traffic, nor does it provide reliable delivery of this traffic; invention in a preferred embodiment thereof, it should be 

each protocol tunnel via L2F is expected to manage flow apparent that the invention can be modified in arrangement 

control and retry itself. Thus, it is only L2F control messages 65 and detail without departing from such principles. I claim all 

which must be retransmitted; this process is described in this modifications and variation coming within the spirit and 

section. scope of the following claims. 
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I claim: 

1. A method for creating a virtual dial-up session from a 
remote client to a local network through an internet service 
provider, comprising: establishing a point-to-point link 
between the remote client and the internet service provider 
using a link level protocol; and 

conducting a layer 2 forwarding protocol between the 
internet service provider and the local network that 
projects the point-to-point link from the internet service 
provider to the local network thereby creating a virtual 
direct dial-up session between the remote client and 
said local network. 

2. A method according to claim 1 including the following 
steps: 

transmitting a request for username and a random number 
from the internet service provider to the remote client; 

keying the random number with a password of the remote 
client at the remote client to obtain a first keyed random 
number; 

transmitting a home gateway name of the local network 
and the first keyed random number from the remote 
client to the internet service provider; 

transmitting the random number and the first keyed ran- 
dom number from the internet service provider to a 
home gateway of the local network; 

mapping the username to a corresponding password at the 
home gateway; 

keying the random number at the home gateway with the 
password corresponding to the username to obtain a 
second keyed random number; 

comparing the first and second keyed random numbers to 
authenticate the remote client at the home gateway; and 

transmitting a tunnel accept message from the local 
network to the internet service provider. 

3. A method according to claim 1 wherein the link level 
protocol comprises at least one of a point-to-point protocol 
(PPP) and a serial line interface protocol (SLIP). 

4. A method according to claim 3 wherein the forwarding 
protocol projects a link control protocol (LCP) from the 
internet service provider to the local network. 

5. A method according to claim 1 including the following 
steps: 

conducting an authentication session between the remote 
client and the internet service provider; and 

forwarding the authentication session to the local wherein 
the authentication session further comprises the follow- 
ing: 

generating a random number, and 

encrypting the random number according to a remote 

client password unknown by the internet service 

provider. 

6. A method according to claim 5 wherein the authenti- 
cation session comprises at least one of a challenge authen- 
tication protocol (CHAP) and password authentication pro- 
tocol (PAP). 

7. A method according to claim 5 including the following 
steps: 

forwarding the random number and the encrypted random 

number to the local network; 
independently encrypting the random number according 

to a stored password corresponding to the remote client 

with the local network; 
comparing the remote client encrypted random number 

with the local network's encrypted random number; 

and 



8,019 

16 

establishing the virtual dial-up session between the inter- 
net service provider and the home gateway when the 
remote client's encrypted random number and the local 
network's encrypted random number match. 
5 8. A method according to claim 1 wherein the internet 
service provider is connected to at least one of a public 
switched telephone network access and an integrated ser- 
vices digital network access. 

9. A method according to claim 1 wherein projecting the 
10 point-to-point link includes the following steps: 

establishing a layer 2 tunnel between the internet service 

provider and the local network; 
encapsulating the link level protocol in the forwarding 

protocol; 

15 forwarding the encapsulated link level protocol through 
the tunnel; 

stripping the forwarding protocol from the link level 
protocol and processing the link level protocol with the 
20 local network as a direct point-to-point connection with 
the remote client. 

10. A method according to claim 1 including identifying 
the remote client as one of a virtual dial-up client and an 
internet service provider client and conducting the forward- 

^ ing protocol only for the virtual dial-up client. 

U. A method for establishing a virtual direct dial-up link 
with a network access server, comprising: 
conducting a point-to-point protocol session with remote 
clients; 

30 identifying remote clients having virtual dial-up 
addresses; 

authenticating remote clients having authorized access to 
a home gateway according to a layer 2 forwarding 
protocol; 

35 establishing a layer 2 tunnel connection with the home 
gateway for authenticated remote clients; and 
projecting the point-to-point protocol session through the 
layer 2 tunnel to the home gateway according to the 
layer 2 forwarding protocol thereby establishing a 

40 virtual direct dial-up link to the home gateway. 

12. A method according to claim 11 wherein the step of 
establishing a tunnel connection comprises the following 
steps: 

45 generating a random number with the network access 
server; 

encrypting the random number with a user password in 
one of the remote clients; 

forwarding a remote client name of the one of the remote 
50 clients, the random number and the encrypted random 
number to the home gateway; 

independently encrypting the random number at the home 
gateway using a stored password corresponding to the 
remote client name; and 
55 establishing a tunnel connection for the one of the remote 
clients if the received encrypted random number 
matches the home gateway's encrypted random num- 
ber. 

13. A method according to claim 11 wherein the step of 
60 projecting comprises encapsulating the point-to-point pro- 
tocol session in a layer 2 forwarding protocol header and 
transmitting the encapsulated point-to-point session through 
the layer 2 tunnel. 

14. A method according to claim 13 wherein the layer 2 
65 forwarding protocol header includes a multiplex identifica- 
tion field for multiplexing multiple remote clients through 
the layer 2 tunnel at the same time. 
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15. A method according to claim 13 wherein the layer 2 
forwarding protocol header includes a client ID field for 
demultiplexing multiple tunnels. 

16. A method according to claim 13 wherein the layer 2 
forwarding protocol header includes a packet key for trans- 
mitting encrypted authentication responses between the net- 
work access server and the home gateway. 

17. A virtual dial-up system, comprising: 
an internet infrastructure; 

a dial-up server connected to the internet infrastructure; 
a private local network; 

a home gateway connected between the private network 
and the internet; 

a remote client connected to the dial-up server, the remote 
client conducting a point-to-point link level session 
with the dial-up server; and 

a virtual dial-up protocol operating on the dial-up server 
for automatically projecting the link level session from 
the dial-up server to the home gateway thereby estab- 
lishing a virtual direct dial-up session between the 
remote client and the private local network through the 
internet infrastructure. 

18. A virtual dial-up system according to claim 17 
wherein the remote client includes a processor for encrypt- 
ing a random number according to a predetermined pass- 
word unknown by the dial-up server. 

19. A virtual dial-up system according to claim 18 
wherein the dial-up server includes a processor for negoti- 
ating a tunnel connection between the remote client and the 
home gateway according to a remote client username, where 
the processor maps the remote client username to the home 
gateway. 

20. A virtual dial-up system according to claim 19 
wherein the dial-up server processor encapsulates the point- 
to-point link level session in a forwarding protocol header 
and forwards the encapsulated link level session with the 
encrypted random number, the random number and the 
remote client username to the home gateway. 

21. A virtual dial-up system according to claim 20 
wherein the home gateway includes one or more processors 
and a look-up table for prestoring the remote client's 
password, the home gateway processor independently 
encrypting the forwarded random number according to the 
prestored password. 

22. A virtual dial-up system according to claim 21 
wherein the home gateway includes a processor for estab- 
lishing a tunnel connection with the remote client according 
to the encrypted random numbers. 

23. A virtual dial-up system according to claim 21 
wherein the home gateway processor provides a firewall that 
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allows access to remote clients according to the encrypted 
random numbers. 

24. A network access server, comprising: 

an input receiving a point-to-point protocol session with 
5 a remote client; 

an output connected to an internet infrastructure for 
transferring information using an internet protocol; and 
a processor and memory connected between the input and 
10 the output for conducting a layer 2 forwarding protocol 
that projects the fink level session through the internet 
infrastructure to a local network independently of the 
internet protocol. 

25. A network access server according to claim 24 
35 wherein the processor attaches a forwarding protocol header 

to the point-to-point protocol session. 

26. A network access server according to claim 25 
wherein the processor negotiates a tunnel through the inter- 
net infrastructure to the local network and transmits the 

20 

forwarding protocol header and the point-to-point protocol 
session over the tunnel. 

27. A network access server according to claim 26 
wherein the tunnel is established independently of a dial-up 

25 phone number used by the remote client for dialing up the 
network access server. 

28. A home gateway, comprising: 

an input connected to an internet infrastructure for receiv- 
ing point-to-point link level packets encapsulated in a 
30 virtual dial-up protocol and transported using an inter- 
net protocol; 
an output connected to a local network; and 
a processor connected between the input and the output 
3 5 for conducting a direct dial-up point-to-point link ses- 
sion through the internet infrastructure to a remote 
client according to the virtual dial-up protocol inde- 
pendently of the internet transport protocol. 

29. A home gateway according to claim 28 wherein the 
40 processor establishes a tunnel connection with a remote 

client according to the virtual dial-up protocol. 

30. A home gateway according to claim 29 wherein the 
processor authenticates the remote client according to the 
virtual dial-up protocol prior to establishing the tunnel 

45 connection. 

31. A home gateway according to claim 30 wherein the 
processor authentication comprises independently encrypt- 
ing a random number according to a prestored remote client 
password. 

50 

***** 
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